docs(service): name the eighth case list view on the SLA page - #1608

Fixes #1541

Description

content/docs/service/sla-and-escalation line 144 stated a count and then hand-copied the roster behind it: "crm_case ships seven" followed by seven names. The eighth view, Unassigned — triage, was missing. All three faces carried it on the same line.

This makes the paragraph true against the source it already cites. Prose only — no src/ change, and the source was not bent to match the paragraph.

What the roster actually is, and how it was derived

Derived from src/views/case.view.ts at origin/main 8223d0aa, by two independent readings that agree:

1. Source structure. The file's four top-level keys are list: (line 14), listViews: (72), form: (396), formViews: (433).
2. Built artifact. pnpm build then reading dist/objectstack.json — the compiled descriptors, not a grep over the authoring file.

Both give the same eight list views, in declaration order:

Two neighbours that look like views to a pattern, and are not — the artifact settles both:

• calendar: at line 63 is a config block, not a view. It is a property of the default list: grid, and in the artifact it reads {"startDateField":"sla_due_date","titleField":"subject","colorField":"priority"} — the calendar visualization binding for that one grid. The dedicated calendar view is the separate sla_calendar entry.
• web_to_case at line 434 is a form view, not a list view. It sits under formViews, alongside the default form:, so it is outside a list-view count. The artifact reports 2 form views and 8 list views.

The name is inserted in source declaration order, between My Open Cases and Escalated Cases.

content/docs/service/cases already said eight and listed all eight. That page was used as a cross-check only; the authority here is src/views/case.view.ts. That page is not touched — it is #1542's surface, dispatched in parallel.

The paragraph's other claims were re-measured, and hold

• "not one of them filters on SLA Violated" — is_sla_violated occurs twice in case.view.ts: as a column on All Cases (line 28) and inside a docblock (line 360). It appears in no view's filter. The eight filters are: none (all_cases), is_closed = false, none, none, owner + status, owner is-null + status, is_escalated = true, status + priority.
• The two breach-filtering surfaces are still dashboard tiles, not views.

The card's second question: should test/docs-view-rosters.test.ts have caught this?

No — the guard's coverage rule does not reach this paragraph's shape. It is not a broken guard; it is a guard that never claimed this page. Three independent reasons, any one of them sufficient:

1. rosterOf() returns null for all three faces. It requires a ## Standard list views heading, in one of six locale spellings. sla-and-escalation carries fourteen headings and none of them matches; the paragraph lives under ## Recommended cadence.
2. The page is not in PAGE_OBJECT. The guard's only crm_case entry is content/docs/service/cases.mdx. The string sla-and-escalation does not appear anywhere in the guard file.
3. The entry unit is a markdown table row. tableBodyRows finds rows by the | --- | delimiter beneath a header. The defect is a running prose sentence with a count word and italic names — zero table rows. The guard's own docstring already records that a roster written as a bulleted list counts zero here; this is not even a bulleted list.

Vacuity guard #1 (every English page with a roster section is mapped to an object) filters on rosterOf(f) !== null, so it is correctly silent rather than failing open. The page never enters the rule, which is why it passed while the defect was live.

Per that answer, and per AGENTS.md §3 (drift-class gates go to the platform) plus epic #1579 retiring local ones: the guard is not extended and no new gate is added. The stop is at the prose.

Type of Change

Documentation update.

Testing

Full pnpm verify chain, run in this worktree at 8385d11c. Each gate below names the property that run actually establishes:

⚠️ No gate reads this paragraph's prose. None of the greens above is evidence that the roster is now right. The evidence for that is the derivation in the section above: eight list views, read off src/views/case.view.ts and off dist/objectstack.json built from it, at origin/main 8223d0aa.

Deviation, reported rather than silently taken

The eighth name is spelled in English on both Chinese faces, matching the seven siblings inside the same sentence — the zh-Hans page names every view in English, fourteen mentions of them, and zero in the zh-CN pack wording. Making that one inserted name Chinese would have produced a mixed-language enumeration; converting the whole enumeration would have rewritten wording the card did not raise, on a page whose convention is page-wide.

The zh-CN pack does carry a Chinese label for all eight (未分派 — 待分诊 for this one), and the sibling zh-Hans Cases roster uses those labels — so the two zh-Hans pages in this section name the same views differently. That is a real inconsistency, adjacent to but distinct from #1552 (which asks about views the pack does not carry). It is filed separately rather than fixed here.

Premise check

• The card's premise is live and unchanged: all three faces said seven and listed seven, at line 144.
• 8223d0aa (PR Clear three platform lint rule families (31 of 90 warnings), and report the rest with named reasons #1605) did touch src/views/case.view.ts twenty minutes before dispatch. Verified independently: the diff is two lines, both inside the form: section (colSpan: 2 becomes span: 'full' on subject and description, lines 402 and 411). No list view was added, removed or renamed. The roster premise survives.

🤖 Generated with Claude Code

Generated by Claude Code